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STATUS OF CLAIMS 

Claims 1-13 and 35-47 are pending in this application. 

No Amendments have been submitted in response to the final Office Action. Thus, the 
status of the claims is as follows: 

Claims 1-7, 9-13, 35-41, and 43-47 stand rejected under 35 U.S.C. § 102(b) as being 
anticipated by U.S. Patent Publication No. 2002/0091645 to Tohyama, et al. (hereinafter 
"Tohyama"). 

Claims 8 and 42 stand rejected under 35 U.S.C. § 103(a) as being obvious over 
Tohyama, et al. in view of U.S. Patent Publication No. 2002/0069148 to Mutschler, et al. 
(hereinafter "Mutschler"). 

Claims 14-34 are canceled. 



STATUS OF AMENDMENTS 

No Amendments have been submitted in response to the final Office Action. 
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SUMMARY OF CLAIMED SUBJECT MATTER 

The subject matter of the independent claims is summarized below with reference 
numerals and reference to the specification and drawings in accordance with 37 CFR §41.37. 

Independent Claim 1 

Independent claim 1 is directed to a method of computing. In one embodiment, at a 
processor in a storage network a service request is received from a user of the storage 
network (Fig. 8, reference numeral 810; paragraph [0054] at page 20, lines 10-20), an amount 
of credit available on a local media is determined for the user of the storage network (Fig. 8, 
reference numeral 815; paragraph [0056] at page 21, lines 5-18), and the service request is 
implemented at the processor when the amount of credit is sufficient to execute the service 
request (Fig. 8, reference numeral 855; paragraph [0056] at page 21, lines 5-18). By contrast, 
when the amount of credit is insufficient to execute the service request, in response to the 
received service request, a token request for a service token is generated (Fig. 8, reference 
numeral 820; paragraph [0057] at page 21, line 19 through page 22, line 7) and transmitted to 
a server communicatively connected to the storage network (Fig. 8, reference numeral 825; 
paragraph [0057] at page 22, lines 8-18). At the server, the token request is validated (Fig. 8, 
reference numeral 830; paragraphs [0059]-[0061] at page 22, line 19 through page 23, line 
22) and a response to the validated token request is transmitted to the processor (Fig. 8, 
reference numeral 835; paragraphs [0062]-[0063] at page 22, lines 1-19). Further, at the 
processor in the storage network the service request is invoked when the response to the 
token request includes at least one service token (Fig. 8, reference numeral 855; paragraphs 
[0064]-[0065] at page 24, line 20-page 25, line 15). 
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Independent Claim 35 

Independent claim 35 is directed to a storage system. In one embodiment, the system 
comprises a local controller comprising a processor an a memory module, wherein the 
memory module comprises logic instructions which, when executed by the processor, 
configure the processor to receive a service request from a user of the storage network (Fig. 
8, reference numeral 810; paragraph [0054] at page 20, lines 10-20), determine an amount of 
credit available on a local media for the user of the storage network (Fig. 8, reference 
numeral 815; paragraph [0056] at page 21, lines 5-18), implement the service request at the 
processor when the amount of credit is sufficient to execute the service request (Fig. 8, 
reference numeral 855; paragraph [0056] at page 21, lines 5-18), and when the amount of 
credit is insufficient to execute the service request, to generate, in response to the received 
service request, a token request for a service token (Fig. 8, reference numeral 820; paragraph 
[0057] at page 21, line 19 through page 22, line 7) and transmit the token request to a server 
communicatively connected to the storage network (Fig. 8, reference numeral 825; paragraph 
[0057] at page 22, lines 8-18). The storage system further comprises a remote server coupled 
to the local controller comprising a processor an a memory module, wherein the memory 
module comprises logic instructions which, when executed by the processor, configure the 
processor to: validate the token request (Fig. 8, reference numeral 830; paragraphs [0059]- 
[0061] at page 22, line 19 through page 23, line 22), and transmit to the processor a response 
to the validated token request (Fig. 8, reference numeral 835; paragraphs [0062]-[0063] at 
page 22, lines 1-19); wherein the processor invokes the service request when the response to 
the token request includes at least one service token (Fig. 8, reference numeral 855; 
paragraphs [0064]-[0065] at page 24, line 20-page 25, line 15). 
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GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

1. Whether claims 1-7, 9-13, 35-41, and 43-47 are properly rejected under 35 U.S.C. 
§ 102(b) as being anticipated by Tohyama. 

2. Whether claims 8 and 42 are properly rejected under 35 U.S.C. § 103(a) as being 
obvious over Tohyama in view of Mutschler. 
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ARGUMENT 

/. Rejections Under 35 U.S.C. $102 

A. Legal Standard for Anticipation 

The standard for lack of novelty, that is, for anticipation, under 35 U.S.C. §102 is one 
of strict identity. To anticipate a claim for a patent, a single prior source must contain all its 
essential elements. Hybritech, Inc. v. Monoclonal Antibodies, Inc., 231 USPQ 81, 90 (Fed. 
Cir. 1986). Invalidity for anticipation requires that all of the elements and limitations of the 
claims be found within a single prior art reference. Scripps Clinic & Research Foundation v. 
Genentech, Inc., 18 USPQ2d 1001 (Fed. Cir. 1991). Every element of the claimed invention 
must be literally present, arranged as in the claim. Richardson v. Suzuki Motor Co., 9 
USPQ2d 1913, 1920 (Fed. Cir. 1989). "The identical invention must be shown in as complete 
detail as is contained in the patent claim." MPEP §2131 (7 th Ed. 1998) (citing Richardson v. 
Suzuki Motor Co., 9 USPQ2d 1913, 1920 (Fed. Cir. 1989)). Furthermore, functional 
language, preambles, and language in "whereby," "thereby," and "adapted to" clauses cannot 
be disregarded. Pac-Tec, Inc. v. Amerace Corp., 14 USPQ2d 1871 (Fed. Cir. 1990). 

"It is by now well settled that the burden of establishing a prima facie case of 
anticipation resides with the Patent and Trademark Office." Ex parte Skinner, 2 USPQ2d 
1788, 1788-1789 (Bd. Pat. Int. 1986) (holding that examiner failed to establish prima facie 
case of anticipation). The examiner has "the burden of proof. . . to produce the factual basis 
for its rejection of an application under sections 102 or 103." In re Piasecki, 745 F.2d 1468, 
1472, 223 USPQ 785, 788 (Fed. Cir. 1984) (quoting In re Warner, 379 F.2d 1011, 1016, 154 
USPQ 173, 177 (CCPA 1967)). Only if that burden is met, does the burden of going forward 
shift to the appellant. 
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B. Tohyama Fails to Disclose Elements Recited in Claims Rejected Under 35 
U.S.C. $102 

1. Claims 1 and 35 

Tohyama cannot anticipate (or render obvious) independent claim 1 because 
Tohyama neither discloses (nor even suggests) limitations recited in independent claim 1. 
Claim 1 is directed to a method computing. The method recites limitations directed to: 

at a processor in a storage network: 

receiving a service request from a user of the storage network; 

determining an amount of credit available on a local media for 
the user of the storage network; 

implementing the service request at the processor when the 
amount of credit is sufficient to execute the service request; and 

when the amount of credit is insufficient to execute the service 

request: 

generating, in response to the received service request, a 
token request for a service token; and 

transmitting the token request to a server 
communicatively connected to the storage network; and 
at the server: 

validating the token request; 

transmitting to the processor a response to the validated token 

request; and 

at the processor in the storage network: 

invoking the service request when the response to the token 
request includes at least one service token. 

The final Action asserts that Tohyama discloses determining an amount of credit 

available on a local media for the user of the storage network, and cites paragraph [0049] to 

support the rejection. Applicants disagree. The cited text reads as follows: 

[0049] In the user account database 3b, there is stored a "user account" such as 
shown in FIG. 2; and writing thereto, reading therefrom and the like are 
managed by the above-mentioned license management program 3a. In the user 
account, there is registered a "user ID (UserlD)" for each user, and in each 
user ID there are stored "user data (Userlnfo)" and "license data (License)". 
The user data is information which the user himself inputs upon user 
registration, in which there is stored data such as "first and last name", 
"address", "telephone number", "email address" and credit card number or 
other such "charging information". As the license data, there is given an 
"application ID (AppID)" for specifying the software (i.e., including such 
content as the software in its entirety, a partial functional program of the 
software, image data that can be used with the software, musical data or the 
like) which is approved for use with respect to each user, and for each 
application ID there are stored a "license base (LicenseBase)" and a "license 
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validity (LicenseValidity)". 



Contrary to the assertion in the Action, nothing in this text discloses (nor even 
suggests) determining an amount of credit available on a local media for the user of the 
storage network, as recited in claim 1. 

The final Action further asserts that Tohyama discloses implementing the service 

request at the processor when the amount of credit is sufficient to execute the service request, 

and cites paragraphs [0049] and [0053] to support the rejection. Applicants disagree. 

Paragraph [0049] is exceipted above. Paragraph [0053] reads as follows: 

[0053] In the application information database 3c, there is stored information 
pertaining to the license conditions for the software of which usage is 
approved, such as is shown in FIG. 5. Specifically, for each "application ID 
(AppID)" there is registered the "license menu (LicenseMenu)". The 
registration is performed by the supplier terminals 1, 2 accessing the license 
management server machine 3 via the internet network, as described above. 
Note that here, even when registration is made for the same software (for 
example, in the case of registering "a-1" and "a-2" which both contain "a" in 
the software ID), it is possible to register a plurality of license menus therefor, 
according to the content of the usage approval (i.e., a function program in "a- 
1", and contents such as image data in "a-2"). Further, even in the case when 
the content of the usage approval is the same for the same software (for 
example, "c-1" and "c-1"), it is possible to register a plurality of license menus 
according to the time elements of the usage-approval ("perpetual" in the top 
"c-1" and the calendar period in the bottom "c-1"). This configuration is 
adopted in order to provide a variety of licensing menus to meet various needs 
of users-including a user who basically wants usage-approval for the entire 
software, a user who only wants usage-approval for a partial functional 
program of the software, a user who wants usage-approval for only a 
predetermined period of time, for example— even for the same single software. 
A"license condition name" included in the license menu of FIG. 5 is a name 
for distinguishing the license conditions (content) for the software is to be 
usage-approved. A "license term/number of times of use" is data indicating the 
time element of the license, in which the software provider sets "perpetual", 
"calendar period" "total duration of time of use" or "total number of times of 
use" for each application ID. A "license fee" is a monetary amount, and a 
"charging method", which is a method of payment thereof, is also selected and 
set by the software supplier. Further, in the "pass issuance regulations", 
"regulations pertinent at time of purchase" -stipulates a type of pass which is 
to be issued, and "regulations pertinent at time of renewing" stipulates how the 
renewing of the pass should be processed according to the charging status. 
The "temporary pass term and number of times of use" and the "pass term and 
number of times of use" stipulate how to adjust the remaining amount of the 
license validity at the time of renewal of the license validity and at the time of 
renewal of the pass. 
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Contrary to the assertion in the Action, nothing in this text discloses (nor even 
suggests) implementing the service request at the processor when the amount of credit is 
sufficient to execute the service request, as recited in claim 1 . 

The final Action further asserts that Tohyama discloses generating, in response to the 
received service request, a token request for a service token, transmitting the token request to 
a server communicatively connected to the storage network, validating the token request, 
transmitting to the processor a response to the validated token request, and invoking the 
service request when the response to the token request includes at least one service token, 
and cites paragraph [0009] to support the rejection. Applicants disagree. Paragraph [0009] 
reads as follows: 

[0009] According to the present invention, in order to achieve the above 
objects, there is provided a software licensing system comprising: a licensing 
terminal for storing a license menu which includes a function, a term and a 
number of times and the like, for which usage may be approved with respect 
to a software for which usage approval is to be given; and a user terminal 
capable of accessing the license menu via a communications line; wherein 
when the licensing terminal creates and sends to the user terminal a pass 
containing the function, the term and the number of times and the like for 
which usage is to be approved based on an agreement/selection by the user 
terminal, the user terminal then sends, to the software for which the usage 
approval is to be given, a run-approval or a run-disapproval command data 
according to information on the function, the term and the number of times of 
use and the like contained in the received pass, and the user terminal then 
becomes able to use the software in a manner in conformity with the content 
of the usage approval in the pass created by the license terminal. 

Contrary to the assertion in the Action, nothing in this text discloses (nor even 
suggests) generating, in response to the received service request, a token request for a service 
token, transmitting the token request to a server communicatively connected to the storage 
network, validating the token request, transmitting to the processor a response to the 
validated token request, and invoking the service request when the response to the token 
request includes at least one service token, as recited in claim 1 . 

In sum, the Action includes erroneous factual findings with respect to the scope and 
content of the prior art. Accordingly, the rejections are improper. 

Claim 35 was rejected on the same basis as claim 1. Applicant traverses the rejection 
of claim 35 based on the same argument applied to claim 1. 
2. Claims 3 and 37 
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Dependent claim 3 depends from, and further defines over and above claim 1 by 
reciting: 

wherein the service request comprises a request for at least one of a 
data mirroring service, a remote copy service, a back-up service, a recovery 
service, or a LUN extension service. 

The final Action asserts that Tohyama discloses these limitations, and cites 
paragraphs [0009] to support the rejection. Applicants disagree. Paragraph [0009] is 
excerpted above. Contrary to the assertion in the Action, nothing in Tohyama discloses (nor 
even suggests) an arrangement wherein the service request comprises a request for at least 
one of a data mirroring service, a remote copy service, a back-up service, a recovery service, 
or a LUN extension service, as recited in claim 3. Therefore, Tohyama cannot anticipate 
claim 3. 

Claim 37 was rejected on the same basis as claim 3. Applicant traverses the rejection 
of claim 37 based on the same argument applied to claim 3. 



3. Claims 4 and 38 

Dependent claim 4 depends from, and further defines over and above claim 1 by 
reciting: 

wherein generating a token request comprises retrieving at least one 
account identifier for an account associated with a device in the storage 
network. 

The final Action asserts that Tohyama discloses these limitations, and cites paragraph 

[0009] and [0124] to support the rejection. Applicants disagree. Paragraph [0009] is 

excerpted above. Paragraph [0124] reads as follows: 

[0124] At the license management server machine 3, the license management 
program 3a reads, from the user account database 3b, the license validity in 
the license data that corresponds to the application ID "a-1" in the received 
portable pass "1" and the user ID "3", which are received (sl26), and verifies 
whether the license validity is in the "Currently Being Moved" state or not 
(s218). In this judgment, the license validity is judged to be in the "Currently 
Being Moved" state only in the case when the following three conditions are 
met: the "remaining amount of the license" contained in the license validity 
has a value greater than zero, the "license status" has a "Valid" value, and the 
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"pass status" has the "Currently Being Moved" value. Here, for the application 
ID "a-1", the "remaining amount of the license" is still unused and indicates 
"perpetual", the "license status" is "Valid" and the "pass status" has been 
updated to the "Currently Being Moved" state at step 174 in FIG. 12; 
therefore, the license validity is judged to be "Currently Being Moved". 
Therefore, the license management program 3a duplicates the "pass status" 
and the "remaining amount of the pass" in the license validity of the portable 
pass "1", and combines these with the application ID "a-1" to make the pass 
"1" (s222). Next, the license management program 3a replaces the "pass 
status" in the license validity which has been read out with a value indicating 
"Valid", updates the license validity (s224), and saves to the user account 
database 3b (s226). Further, the pass "1" created at step 222 is sent to the user 
terminal 6 (s228). 

Contrary to the assertion in the Action, nothing in Tohyama discloses (nor even 
suggests) an arrangement wherein generating a token request comprises retrieving at least 
one account identifier for an account associated with a device in the storage network, as 
recited in claim 4. Therefore, Tohyama cannot anticipate claim 4. 

Claim 38 was rejected on the same basis as claim 4. Applicant traverses the rejection 
of claim 38 based on the same argument applied to claim 4. 



4. Claims 5 and 39 

Dependent claim 5 depends from, and further defines over and above claim 1 by 
reciting: 

wherein generating a token request comprises incorporating into the 
token request information identifying the seivice request. 

The final Action asserts that Tohyama discloses these limitations, and cites 
paragraphs [0009] to support the rejection. Applicants disagree. Paragraph [0009] is 
excerpted above. Contrary to the assertion in the Action, nothing in Tohyama discloses (nor 
even suggests) an arrangement wherein generating a token request comprises incorporating 
into the token request information identifying the service request, as recited in claim 5. 
Therefore, Tohyama cannot anticipate claim 5. 

Claim 39 was rejected on the same basis as claim 5. Applicant traverses the rejection 
of claim 39 based on the same argument applied to claim 5. 
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5. Claims 6 and 40 

Dependent claim 6 depends from, and further defines over and above claim 5 by 
reciting: 

wherein generating a token request comprises incorporating into the 
token request information identifying the service request. 

The final Action asserts that Tohyama discloses these limitations, and cites 
paragraphs [0009] to support the rejection. Applicants disagree. Paragraph [0009] is 
excerpted above. Contrary to the assertion in the Action, nothing in Tohyama discloses (nor 
even suggests) an arrangement wherein generating a token request comprises incorporating 
into the token request information identifying the service request, as recited in claim 6. 
Therefore, Tohyama cannot anticipate claim 6. 

Claim 40 was rejected on the same basis as claim 6. Applicant traverses the rejection 
of claim 40 based on the same argument applied to claim 6. 



6. Claims 7 and 41 

Dependent claim 7 depends from, and further defines over and above claim 5 by 
reciting: 

wherein validating the token request comprises determining whether 
the account associated with the at least one account identifier comprises 
sufficient credit to receive a token. 

The final Action asserts that Tohyama discloses these limitations, and cites paragraph 

[0051] to support the rejection. Applicants disagree. Paragraph [0051] reads as follows: 

[005 1 ] Further, in the license validity, there is included data pertaining to the 
current license status regarding each application ID. Namely, this is respective 
data of a "remaining amount of the license", the "license status" and the "pass 
status", which are shown in FIG. 4. Among these, data to be written in the 
"remaining amount of the license" is comprised of the following: the "x" in the 
case where the usage-approval for the application ID is "perpetual"; a start 
date and time, and an end date and time in the case when the usage-approval is 
for the "calendar" period; a total remaining duration of time in the case when 
the usage-approval is for the "total duration of time of use"; and a remaining 
number of times of use in the case where the usage-approval is for the "total 
number of times of use". Further, the license status is composed of data 
indicating whether the license is valid or not, in accordance with actual 
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performance of a payment for the charge applied. 

Contrary to the assertion in the Action, nothing in Tohyama discloses (nor even 
suggests) an arrangement wherein validating the token request comprises determining 
whether the account associated with the at least one account identifier comprises sufficient 
credit to receive a token, as recited in claim 7. Therefore, Tohyama cannot anticipate claim 
7. 

Claim 41 was rejected on the same basis as claim 7. Applicant traverses the rejection 
of claim 41 based on the same argument applied to claim 7. 

8. Claims 9 and 43 

Dependent claim 9 depends from, and further defines over and above claim 1 by 
reciting: 

wherein the response to the token request comprises at least one of: 
an account identifier; 
an account balance; 

a code, decipherable by the processor, granting or denying 
permission to invoke the service call; and 

a software module, executable by the processor, for invoking 
the service call. 

The final Action asserts that Tohyama discloses these limitations, and cites 
paragraphs [009] and [0124] to support the rejection. Applicants disagree. The cited text is 
excerpted above. Contrary to the assertion in the Action, nothing in the cited text discloses 
(nor even suggests) an arrangement wherein the response to the token request comprises at 
least one of: an account identifier, an account balance, a code, decipherable by the processor, 
granting or denying permission to invoke the service call, and a software module, executable 
by the processor, for invoking the service call, as recited in claim 9. Therefore, Tohyama 
cannot anticipate claim 9. 

Claim 43 was rejected on the same basis as claim 9. Applicant traverses the rejection 
of claim 43 based on the same argument applied to claim 9. 



9. Claims 11 and 45 
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Dependent claim 1 1 depends from, and further defines over and above claim 1 by 
reciting: 

wherein the response to the token request comprises a software 
module, executable by the processor, for invoking the service call. 

The final Action asserts that Tohyama discloses these limitations, and cites paragraph 
[0014], [0048], and [0086] to support the rejection. Applicants disagree. The cited text reads 
as follows: 

[0014] Further, the computer program and the recording medium according to 
the present invention are constructed as a computer program and computer 
readable recording medium for storing the program, which computer program 
executes the following by means of a control means of the licensing terminal 
which can connect via the communications line to the user terminal that uses 
the software for which usage approval has been given and which stores the 
license menu containing the function, the term and the number of times and 
the like for which usage may be approved for the software: processing (a) 
being processing for sending to the user terminal a license menu that pertains 
to the software; processing (b) being processing for receiving 
agreement/selection data that contains the function, the term and the number 
of times and the like that the user terminal agreed/selected from the license 
menu, and creating the pass that contains information on the function, the 
usage period and the like for which usage is to be approved for the software, 
based on the agreement/selection data; and processing (c) being processing for 
sending the pass to the user terminal. 

[0048] The license management server machine 3 is the core of the licensing 
system of the present example; as such, a license management program 3 a, 
which is executed by the CPUs that serve as the control means (not shown), 
accesses a provided user account database 3b and application information 
database 3c, and carries out communications controls with the supplier 
terminals 1 and 2 and the user terminal 4. 

[0086] The license controller 4a judges whether the received pass "1" is valid 
or not (s52, s54). In this validity judgment, the judgment of "Valid" is made 
only in the case where the pass status of the pass "1" of FIG. 8(a) indicates 
"Valid", and the remaining amount of the pass still has some amount 
remaining. It is being assumed, here, that the pass status of the pass "1" is 
"Valid", and that the remaining amount of the pass is "-(perpetual)", so the 
pass "1" is valid. Therefore, the license controller 4a creates command data to 
approve the running of the application ID "a-1" contained in the pass "1", and 
sends this to the software installed in the user terminal 4 (s56). Accordingly, 
the user terminal 4 can now use the function program of the application ID "a- 
1", which could not be used previously for the software. 
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Contrary to the assertion in the Action, nothing in Tohyama discloses (nor even 
suggests) an arrangement wherein the response to the token request comprises a software 
module, executable by the processor, for invoking the service call, as recited in claim 1 1 . 
Therefore, Tohyama cannot anticipate claim 1 1. 

Claim 45 was rejected on the same basis as claim 1 1 . Applicant traverses the 
rejection of claim 45 based on the same argument applied to claim 11. 

10. Claims 12 and 46 
Dependent claim 12 depends from, and further defines over and above claim 1 1 by 

reciting: 

wherein the processor in the storage network: 

receives the response to the token request; and 

executes the software module to invoke the service request. 

The final Action asserts that Tohyama discloses these limitations, and cites 
paragraphs [0086] to support the rejection. Applicants disagree. The cited text is excerpted 
above. Contrary to the assertion in the Action, nothing in the cited text discloses (nor even 
suggests) an arrangement wherein the processor in the storage network receives the response 
to the token request, and executes the software module to invoke the service request, as 
recited in claim 12. Therefore, Tohyama cannot anticipate claim 12. 

Claim 46 was rejected on the same basis as claim 12. Applicant traverses the 
rejection of claim 46 based on the same argument applied to claim 12. 

8. Claims 13 and 47 
Dependent claim 9 depends from, and further defines over and above claim 1 by 

reciting: 

wherein the processor maintains account information associated with 
one or more storage devices, and wherein the processor updates account 
information to reflect execution of the service request. 

The final Action asserts that Tohyama discloses these limitations, and cites paragraph 
[0124] to support the rejection. Applicants disagree. The cited text is excerpted above. 
Contrary to the assertion in the Action, nothing in the cited text discloses (nor even suggests) 
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an arrangement wherein the processor maintains account information associated with one or 
more storage devices, and wherein the processor updates account information to reflect 
execution of the service request, as recited in claim 13. Therefore, Tohyama cannot 
anticipate claim 13. 

Claim 47 was rejected on the same basis as claim 13. Applicant traverses the 
rejection of claim 47 based on the same argument applied to claim 13. 

//. Rejections Under 35 U.S.C. §103 

A. Legal Standard for Obviousness 

To establish a prima facie case of obviousness, three basic criteria must be met. First, 
there must be some suggestion or motivation, either in the references themselves or in the 
knowledge generally available to one of ordinary skill in the art, to modify the reference or to 
combine reference teachings. Second, there must be a reasonable expectation of success. 
Finally, the prior art reference (or references when combined) must teach or suggest all the 
claim limitations. (See, MPEP § 2143). To establish prima facie obviousness of a claimed 
invention, all the claim limitations must be taught or suggested by the prior art. In re Royka, 
490 F.2d 981, 180 USPQ 580 (CCPA 1974). Moreover, all words in a claim must be 
considered in judging the patentability of that claim against the prior art. In re Wilson, 424 
F.2d 1382, 1385, 165 USPQ 494, 496 (CCPA 1970). 

As with anticipation, the Examiner bears the burden of proof to provide a factual 
basis to support a rejection under 35 U.S.C. §103. In re Piasecki, 745 F.2d 1468, 1472, 223 
USPQ 785, 788 (Fed. Cir. 1984) (quoting In re Warner, 379 F.2d 101 1, 1016, 154 USPQ 
173, 177 (CCPA 1967)). Only if that burden is met, does the burden of going forward shift to 
the Appellant. 

B. Tohyama, Alone or in Combination with Mutschler, Fails to Disclose Elements 
Recited in Claims 8 and 42 

Claims 8 and 42 were rejected under 35 U.S.C. § 103(a) as being obvious over 
Tohyama in view of Mutschler. Applicants traverse these rejections. 
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Initially, Applicant contends that the Action fails to establish a prima facie case of 
obviousness because the Action fails to make the necessary factual findings required under 

Teleflex Inc. v. KSR Int'l, Co. 550 U.S. , 82 USPQ 2d 1385 (2007), as interpreted by the 

Examination Guidelines for Determining Obviousness Under 35 U.S.C. §103 in View of the 
Supreme Court Decision in KSR International Co. v. Teleflex Inc., published October 10, 
2007. For example, the Action lacks any factual findings with regard to on the level of 
ordinary skill in the art. 

Further, Applicants assertthat the Action fails to establish a prima facie case of 
obviousness because there are errors in the factual findings regarding the scope and content 
of the prior art underlying the obviousness rejection. . 

Dependent claim 8 depends from, and further defines over and above claim 7 by 

reciting: 

further comprising retrieving information from a third-party credit 

bureau. 

Contrary to the assertion in the final Action, nothing in Tohyama discloses (nor even 
suggests) the limitations in claims 7, 5, 4, and 1, from which dependent claim 8 depends. 
Therefore, Tohyama, alone or in combination with Mutschler, cannot render obvious claim 8. 

Claim 42 was rejected on the same basis as claim 8. Applicant traverses the rejection 
of claim 42 based on the same argument applied to claim 8. 
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CONCLUSION 

The cited references fail to disclose or suggest limitations of appellants' claims. 
Therefore, the cited cannot be used to establish the required prima-facie case of anticipation 
under 35 U.S.C. §102 or of obviousness under 35 U.S.C. §103 . Accordingly, Appellants urge 
the Board to reverse the examiner's rejections of the pending claims. 



Respectfully submitted, 

Jed W. Caven 

Caven & Aghevli LLC 

Attorney for Appellants 

/Jed W. Caven, Reg. No. 40,551/ 

Jed W. Caven 
Registration No. 40,551 
(720) 841-9544 

Date: December 4, 2008 
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Claims Appendix 

1 . A method of computing, comprising: 
at a processor in a storage network: 

receiving a service request from a user of the storage network; 
determining an amount of credit available on a local media for the user of the storage 
network; 

implementing the service request at the processor when the amount of credit is 
sufficient to execute the service request; and 

when the amount of credit is insufficient to execute the service request: 

generating, in response to the received service request, a token request for a 
service token; and 

transmitting the token request to a server communicatively connected to the 
storage network; and 
at the server: 

validating the token request; 

transmitting to the processor a response to the validated token request; and 
at the processor in the storage network: 

invoking the service request when the response to the token request includes at least 
one service token. 

2. The method of claim 1, wherein the service request is generated by at least one of a 
user of a device in the storage network or by a processor communicatively connected to the 
storage network. 

3. The method of claim 1, wherein the service request comprises a request for at least 
one of a data mirroring service, a remote copy service, a back-up service, a recovery service, 
or a LUN extension service. 

4. The method of claim 1 , wherein generating a token request comprises retrieving at 
least one account identifier for an account associated with a device in the storage network. 

5. The method of claim 4, wherein generating a token request comprises incorporating 
into the token request information identifying the service request. 

6. The method of claim 5, wherein validating the token request comprises validating the 
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at least one account identifier associated with the service request. 

7. The method of claim 5, wherein validating the token request comprises determining 
whether the account associated with the at least one account identifier comprises sufficient 
credit to receive a token. 

8. The method of claim 7, further comprising retrieving information from a third-party 
credit bureau. 

9. The method of claim 1, wherein the response to the token request comprises at least 
one of: 

an account identifier; 
an account balance; 

a code, decipherable by the processor, granting or denying permission to invoke the 
service call; and 

a software module, executable by the processor, for invoking the service call. 

10. The method of claim 1 , further comprising updating account information at the 
processor in the storage network. 
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1 1 . The method of claim 1 , wherein the response to the token request comprises a 
software module, executable by the processor, for invoking the service call. 

12. The method of claim 11, wherein the processor in the storage network: 
receives the response to the token request; and 

executes the software module to invoke the service request. 

13. The method of claim 1 1, wherein the processor maintains account information 
associated with one or more storage devices, and wherein the processor updates account 
information to reflect execution of the service request. 
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35. A storage system, comprising: 

a local controller comprising a processor an a memory module, wherein the memory 
module comprises logic instructions which, when executed by the processor, configure the 
processor to: 

receive a service request from a user of the storage network; 
determine an amount of credit available on a local media for the user of the 
storage network; 

implement the service request at the processor when the amount of credit is 
sufficient to execute the service request; and 

when the amount of credit is insufficient to execute the service request: 

generate, in response to the received service request, a token request 
for a service token; and 

transmit the token request to a server communicatively connected to 
the storage network; and 

a remote server coupled to the local controller comprising a processor an a memory module, 
wherein the memory module comprises logic instructions which, when executed by the 
processor, configure the processor to: 
validate the token request; and 

transmit to the processor a response to the validated token request; and 
at the processor in the storage network, 

wherein the processor invokes the service request when the response to the token 
request includes at least one service token. 

36. The storage system of claim 35, wherein the service request is generated by at least 
one of a user of a device in the storage network or by a processor communicatively connected 
to the storage network. 

37. The storage system of claim 35, wherein the service request comprises a request for at 
least one of a data mirroring service, a remote copy service, a back-up service, a recovery 
service, or a LUN extension service. 

38. The storage system of claim 35, wherein the memory module on the local controller 
comprises logic instructions which, when executed by the processor, configure the processor 
to retrieve at least one account identifier for an account associated with a device in the 
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storage network. 

39. The storage system of claim 35, wherein the memory module on the local controller 
comprises logic instructions which, when executed by the processor, configure the processor 
to incorporate into the token request information identifying the service request. 

40. The storage system of claim 35, wherein the memory module on the remote server 
comprises logic instructions which, when executed by the processor, configure the processor 
to validate the at least one account identifier associated with the service request. 

41 . The storage system of claim 35, wherein the memory module on the remote server 
comprises logic instructions which, when executed by the processor, configure the processor 
to determine whether the account associated with the at least one account identifier comprises 
sufficient credit to receive a token. 

42. The storage system of claim 35, w herein the memory module on the remote server 
comprises logic instructions which, when executed by the processor, configure the processor 
to retrieve information from a third-party credit bureau. 

43. The storage system of claim 35, wherein the response to the token request comprises 
at least one of: 

an account identifier; 
an account balance; 

a code, decipherable by the processor, granting or denying permission to invoke the 
service call; and 

a software module, executable by the processor, for invoking the service call. 

44. The storage system of claim 35, wherein the memory module on the local controller 
comprises logic instructions which, when executed by the processor, configure the processor 
to update account information at the processor in the storage network. 

45. The storage system of claim 35, wherein the response to the token request comprises a 
software module, executable by the processor, for invoking the service call. 

46. The storage system of claim 45, wherein the memory module on the local controller 
comprises logic instructions which, when executed by the processor, configure the processor 
to: 

receive the response to the token request; and 
23 



execute the software module to invoke the service request. 
47. The storage system of claim 45, wherein the processor maintains account information 
associated with one or more storage devices, and wherein the processor updates account 
information to reflect execution of the service request. 
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Evidence Appendix 



None 



Related Proceedings Appendix 

None 
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